\chapter{Prototyp Design}
\label{design}
In diesem Kapitel werden die für die Implementierung zur Verfügung stehenden Elemente und deren Zusammenhänge aufgeführt und erklärt. Da sich die Prototypen in ihrer Funktionsweise unterscheiden, werden die einzelnen Prototypen separat aufgeführt.


\section{APE}
APE Server ist komplett in der Programmiersprache C implementiert und erfordert mindestens Kernel Linux 2.6.19+. Es sind keine weiteren Mindestanforderungen oder Paketinstallation erforderlich. APE ist ein HTTP-Streaming-Server, welcher die Methoden \textit{GET} und \textit{POST} des HTTP-Protokolls implementiert. APE ist ausschliesslich ein Push-Server und ersetzt keinen Webserver wie Apache, Tomcat oder Lighttpd.

\subsection{Datenaustausch}
Die APE-Dokumentation definiert folgende Terminologien:\\

\begin{itemize}
	\item \textit{Raw}: Nachricht von Server zu Client
	\item \textit{Command}: Nachricht von Client zu Server
	\item \textit{Channel}: Kanal mit welchem übertragene Informationen gefiltert werden können. Clients melden sich einem Channel an, um spezifische Informationen vom Server zu erhalten.
\end{itemize}

Raws und Commands sind Json-Objekte. Jede Raw und Command wird mit einem Namen identifiziert und beinhaltet ein Objekt, welches die effektiven Daten enthält.

\subsubsection{Raw}
Alle Raws werden in folgendem Format an den Client geschickt:

\begin{lstlisting}[numbers=none,label=raw-format,caption=Grundstruktur einer Raw.]
[
Object :
    raw: <raw_name>
    time: <unix_time_stamp>
    data: <Object>
]
\end{lstlisting}

Ein konkretes Beispiel einer Raw sieht folgendermassen aus:

\begin{lstlisting}[numbers=none,label=raw-basic-example,caption=Beispiel einer Raw] 
[{"raw":"login","time":"1304414075","data":{"sessid":"1234"}}]
\end{lstlisting}

Das obenstehende Beispiel illustriert eine mögliche Raw, die ein Server nach Einloggen des Clients zurückschickt. Der Identifikationsname ist \textit{login} und \textit{1234} ist die vergangene Anzahl Sekunden die seit erstem Januar 1970 vergangen sind (Unix Timestamp). Das Objekt \textit{data} beinhaltet hier die Session-ID, welche der Client benötigt um auf der Webseite eingeloggt zu sein.

Es ist möglich mehrere Raws zur selben Zeit an den Client zu schicken, indem man die Raws in ein Json-Array verpackt.

\subsubsection{Command}
Commands werden via HTTP-Request an die \textit{GET} oder \textit{POST} Methoden an den Server geschickt. Die Grundstruktur einer Command sieht folgendermassen aus:

\begin{lstlisting}[numbers=none,label=command-format,caption=Grundstruktur einer Command] 
[
Object :
    cmd: <cmd_name>
    chl: <channel_name>
    sessid: <session_id> (optional)
    params: <Object>
]
\end{lstlisting}

Ein konkretes Beispiel einer Command sieht folgendermassen aus:

\begin{lstlisting}[numbers=none,label=command-basic-example,caption=Beispiel einer Command] 
[{"cmd":"command_name","chl":"example","sessid":"1234","params":{"foo":"bar"}}]
\end{lstlisting}

Es ist möglich mehrere Commands zur selben Zeit an den Server zu schicken, indem man die Commands in ein Json-Array verpackt.




\subsection{Sequenzdiagramm}
Wie im Kapitel \ref{prototyp-spezifikation} beschrieben, wird per Knopfdruck auf Clientseite das Versenden einer Nachricht an den Server ausgelöst. Der Server reagiert anschliessend auf diese Nachricht, indem er an alle angemeldeten Clients eine Nachricht zurückschickt. Die Nachrichten beinhalten jeweils die Serverzeit bzw. Clientzeit, damit die in der Zielsetzung definierten Zeitmessungen durchgeführt werden können. Auf Serverseite wird nach dem ersten Auslösen jede Sekunde eine Nachricht an alle angemeldeten Clients geschickt.

Dieser ganze Vorgang wird mit der Terminologie der APE-Spezifikation wie folgt ausgedrückt:

Jeder Client meldet sich einem Channel an. Per Knopfdruck wird das Versenden einer Command an den Server ausgelöst. In dieser Command wird die Clientzeit (aktuelle Millisekunde) des Zeitpunktes des Knopfdruckes gespeichert, damit anschliessend auf Serverseite berechnet werden kann, wie lange die Command gebraucht hat, um bis zum Server zu gelangen (siehe Ziel 2, Kapitel \ref{ziel}). Sobald der Server die Command erhalten hat, berechnet er den soeben erwähnten Zeitunterschied und gibt dieser in der Serverkonsole aus. Der Server reagiert anschliessend auf die erhaltene Command, indem er an alle angemeldeten Clients des selben Channels eine Raw zurückschickt. Die Raw beinhaltet den Zeitpunkt des Versands auf Serverseite (in Millisekunden). Sobald die Clients die Raw vom Server erhalten haben, berechnen sie den Zeitunterschied zwischen Versand auf Serverseite und Erhalt auf Clientseite und geben diese im Browserfenster aus (siehe Ziel 1, Kapitel \ref{ziel}). Das untenstehende Sequenzdiagramm veranschaulicht den gesammten beschriebenen Ablauf:

\EPSFIGTEXTWIDTH{figures/sequence-diagram-prototyp-ape.eps}{Sequenzdiagramm des Prototyps}{seq1}




\section{Streamhub \& GWT}
Streamhub ist ein in Java implementierter Push Server, der aber auch direkt als Webserver dienen kann. Dies ist jedoch laut Streamhub für grössere Projekte nicht zu empfehlen, da Streamhub nicht für diesen Zweck entwickelt wurde.\\
Im Gegensatz zum APE Framework ist die Streamhub-GWT Lösung weniger transparent. Auf Clientseite wird Java-Code geschrieben, welcher anschliessend in komprimierten und optimierten JavaScript-Code umgewandelt wird. Daher ist unklar, wie der effektive Datenaustausch bei Streamhub funktioniert. Der Entwickler ist somit vom eigentlichen Geschehen abgeschirmt.

\subsection{Datenaustausch}
Der Client muss sich als erstes mit dem Streamhubserver verbinden. Sobald dies geschehen ist, kann sich der Client bei einem oder mehreren Kanälen (Channels) registrieren (wie bei APE). Bei der Channelregistrierung wird eine Listener Klasse angegeben, die für das Empfangen von Nachrichten auf diesem Channel verantwortlich ist.

Auf Seite des Servers werden drei verschiedene Listeners definiert, die das Empfangen von An- und Abmeldungen, sowie das Empfangen von Clientnachrichten verwalten.

\subsection{Sequenzdiagramm}
Der Ablauf des Sequenzdiagramm ist der selbe wie wir es bereits bei APE gesehen haben. Da wir jedoch nicht genau wissen in welchem Format die Daten übermittelt werden sind die Json-Objekte auf der Abbildung \ref{seq1} wegzudenken.

\section{Gwt-comet}
\label{gwt-comet}
Im Kapitel \label{framework-auswahl} "`Framework Auswahl'', wurde Cometd4Gwt für die Prototypimplementierung ausgewählt. Folgender Satz ist im Abschnitt "`Cometd4Gwt'' zu finden:

\begin{quote}
\textit{Folgende Punkte sind Grund für die Nahauswahl des Frameworks "`Cometd''}
\end{quote}

Dem Autor war zu diesem Zeitpunkt nicht klar, dass Cometd4Gwt nicht von den offiziellen Cometd-Herstellern entwickelt wurde und mit der Cometd-Community nichts zu tun hat. Dies ist zu erkennen, da im obenstehenden Satz "`Cometd'' und nicht "`Gwt4Comet'' steht. Einzig die veröffentlichte Version von Cometd wurde in das Projekt integriert. Nach ersten Implementierungsversuchen stellte sich heraus, dass Comet4Gwt nicht mit den neusten GWT-Versionen kompatibel ist. Aus diesen Gründen wurde Design und Implementierung mit dem Framework Cometd4Gwt verworfen. Anstelle wurde das Framework "`Gwt-comet'' zur Nahauswahl hinzugezogen.

Wie bereits im Kapitel \ref{framework-uebersicht} "`Framework Übersicht'' erwähnt, ist Gwt-comet kompatibel mit Glassfish oder Jetty. Aufgrund der hohen Komplexität des Glassfish-Servers wurde der bereits in GWT integrierte Jetty-Server für dieses Projekt vorgezogen.

Da der Quellcode von Gwt-comet offen zugänglich ist, ist die Gwt-comet-Variante transparenter als die Streamhub-GWT-Lösung.

\subsection{Datenaustausch}
Wenn GWT mit dem integrierten Jetty-Webserver verwendet wird, müssen sogenannte "`Servlets'' definiert werden. Ein Servlet ist eine Klasse, die beim Serverstart geladen wird. Das geladene Servlet reagiert anschliessend auf bestimmte URL-Anfragen, nimmt Eingangsparameter entgegen und antwortet mit einem entsprechenden Rückgabewert. Dieses Verhalten wird in der GWT-Terminologie ein "`Service'' genannt.

Der Client hat auf seiner Seite ein definiertes Interface des Server-Service und kann somit die Methoden des Service per "`Remote Procedure Call'' RPC aufrufen. Ähnlich wie bei Streamhub, muss sich der Client zuerst beim Server (Service) registrieren bevor der Datenaustausch beginnen kann. Ebenfalls so wie bei Streamhub, muss bei der Anmeldung eine Listener Klasse angegeben werden, die für das Empfangen von Nachrichten verantwortlich ist. Der grosse Unterschied zu Streamhub ist, dass nur ein einziger Listener registriert werden kann, welcher für alle eingehenden Server-Pushs verantwortlich ist. Zusammengefasst ausgedrückt, können verschiedene Services vom Client aus benutzt werden, für welche jedoch schlussendlich nur ein Listener auf Clientseite verantwortlich ist. Dies bedeutet, dass auf Seite des Clients, je nach Nachricht, unterschiedlich reagiert werden muss. Nachricht vom Typ \textit{A} von Service \textit{X} und Nachricht vom selben Typ \textit{A} von Service \textit{Y} können dabei nicht direkt unterschieden werden. Einzig die Art der Nachricht (Typ) kann unterschieden werden.

Bevor der Client Daten an den Server schicken kann, müssen diese zuerst serialisiert werden (Informationen über Serialisierung siehe \url{http://de.wikipedia.org/wiki/Serialisierung}) \cite{serialisierung}. Sobald der Server eine Nachricht vom Client erhält, müssen die erhaltenen Daten zuerst wieder in ein Objekt umgewandelt werden (Deserialisierung).

\subsection{Sequenzdiagramm}
Im Gegensatz zu APE, kann der Client bei Gwt-comet direkt bestimmen welche Methode auf Serverseite (Service) aufgerufen werden soll. Der Server muss nicht zuerst die Nachricht vom Client analysieren und entscheiden welche Methode er aufrufen soll. Der Client kann also die Zeit des Knopfdruckes direkt als Methodenparameter dem Server übergeben. Dieser nimmt diesen Parameter entgegen und kann somit den Zeitunterschied zwischen Knopfdruck des Clients und Erhalt der Nachricht ausrechnen (siehe Kapitel \ref{prototyp-spezifikation}, Prototyp Spezifikation, Ziel 2). Damit ebenfalls Ziele 1 und 3 erreicht werden können, kreiert der Server ein neues Objekt, in welchem er seine aktuelle Serverzeit speichert. Dieses Objekt schickt er anschliessend an alle Clients, die bei diesem Service angemeldet sind. Sobald die Clients dieses Objekt erhalten können sie den Zeitunterschied zwischen Versenden vom Server und Erhalt beim Client ausrechnen.

\EPSFIGTEXTWIDTH{figures/sequence-diagram-prototyp-gwt-comet.eps}{Sequenzdiagramm des Prototyps}{seq2}